#AI 辅助编程

avatar
宝玉
1周前
YC 编写的 《Vibe Coding 指南》 与 AI 结对编程，就像是拥有了一位虽然才华横溢、但偶尔会“走神”的实习生。它能在一小时内帮你完成过去需要一周才能搞定的工作，但有时也会在你项目的核心代码里悄悄埋下一个“惊喜”。 那么，如何才能驾驭好这位强大的编程伙伴呢？我们采访了多位利用 AI 编码的创始人，总结出了这套实用的“AI 协作编程指南”。 规划流程 好的开始是成功的一半。别指望“凭感觉编程” (Vibe Coding) 能带你走向成功。与 AI 高效协作的第一步，是制定一个清晰的路线图。 • 制定周详计划: 首先，和你的 AI 助手一起，在 Markdown 文件里写一份详尽的实施计划。 • 评审与精简: 审视这份计划，删掉不必要的部分。如果某个功能过于复杂，果断地将其标记为“暂不开发”。 • 控制项目范围: 单独开辟一个“未来想法”区域，把暂时不做的好点子都放进去，这能帮助你保持专注。 • 小步快跑，增量实现: 按部就班，一部分一部分地去实现，不要试图一口气吃成个胖子。 • 追踪进度: 每当一个部分成功实现后，让 AI 将其标记为“已完成”。 • 频繁提交: 在进入下一个环节之前，确保每个能正常工作的部分都已提交到 Git。 版本控制策略 当你的 AI 伙伴开始“自由发挥”时，版本控制系统就是你最可靠的后悔药。 • 将 Git 奉为圭臬: 不要完全依赖 AI 工具自带的撤销功能，Git 才是你的生命线。 • 从干净的起点开始: 每开发一个新功能，都确保你的 Git 工作区是干净的。 • 果断重置: 如果 AI 开始“天马行空”，让代码变得一团糟，别犹豫，立即使用 git reset --hard HEAD 命令回到上一个正常的状态。 • 避免问题滚雪球: 一次又一次失败的尝试，只会在错误的代码上堆砌更多错误的代码。 • 清爽地实现: 当你最终找到解决方案后，先重置代码库，然后在一个干净的版本上重新、清爽地实现它。 测试框架 和 AI 协作时，测试不仅是保证质量的手段，更是防止它“好心办坏事”的护栏。 • 优先进行高层级测试: 相比单元测试，优先编写端到端的集成测试。 • 模拟用户行为: 通过模拟真实用户在网站或应用中的点击操作来测试功能。 • 捕获“回归”问题: 大语言模型 (LLM) 常常会在修改代码时，无意中破坏一些不相关的功能。测试能帮你及时发现这些问题。 • 先测试，再前进: 在开始下一个新功能之前，确保所有现有的测试都能通过。 • 用测试作为护栏: 一些创始人建议，可以先编写测试用例，这能为 AI 的工作提供清晰的边界和目标。 高效修复 Bug 当 Bug 出现时，别单打独斗，让 AI 帮你分析。 • 善用错误信息: 很多时候，你只需要把完整的错误信息直接复制粘贴给 AI，它就能给出解决方案。 • 先分析，再动手: 在急于写代码修复之前，先让 AI 分析并列出几种可能导致 Bug 的原因。 • 失败后就重置: 每次修复尝试失败后，都回到干净的代码状态再进行下一次尝试。 • 添加日志: 在关键位置添加日志记录，能帮你和 AI 更好地理解代码的实际运行情况。 • 切换模型: 如果一个 AI 模型卡住了，不妨换个别的模型试试，也许会有意想不到的效果。 • 清爽地修复: 和开发新功能一样，一旦找到 Bug 的根源，就重置代码，然后干净利落地实现修复方案。 AI 工具优化 工欲善其事，必先利其器。充分配置你的 AI 工具，能让协作效率更上一层楼。 • 创建指令文件: 在项目里创建专门的指令文件（比如 cursor.rules, windsurf.rules, ），把详细的指令和规范写在里面。 • 本地文档: 把需要用到的 API 文档下载到项目文件夹里，这能让 AI 的回答更加准确。 • 多工具协作: 有些创始人甚至会在同一个项目上同时运行 Cursor 和 Windsurf 这样的不同工具。 • 各取所长: 通常，Cursor 在处理前端任务时速度更快，而 Windsurf 更擅长处理耗时较长的复杂任务。 • 货比三家: 让不同的工具生成多种解决方案，然后挑选出最好的那一个。 复杂功能开发 面对复杂的大型功能，关键在于“化整为零”。 • 创建独立原型: 先在一个全新的、干净的代码库里，把复杂功能的核心部分构建成一个独立的原型。 • 提供参考范例: 指向一个已经能正常工作的代码示例，让 AI 学习和模仿。 • 明确边界: 保持外部 API 的一致性，允许 AI 在内部自由修改和重构。 • 模块化架构: 基于服务的模块化架构，由于其边界清晰，比庞大的单体仓库 (monorepo) 更适合与 AI 协作。 技术栈的选择 你的技术选择，会直接影响 AI 的发挥。 • 成熟框架表现更佳: 像 Ruby on Rails 这样拥有 20 年发展历史和大量惯例的框架，AI 对其理解更深。 • 训练数据是关键: 像 Rust、Elixir 这样的新兴语言，由于可供 AI 学习的公开代码较少，AI 的表现可能会稍逊一筹。 • 模块化是王道: 把代码拆分成更小的文件，不仅方便人类阅读，也更容易让 AI 理解和处理。 • 避免“万行神文件”: 不要让单个文件膨胀到数千行，这会成为你和 AI 的噩梦。 编码之外的妙用 AI 的能力远不止写代码。 • DevOps 自动化: 让 AI 帮你配置服务器、DNS 和托管服务。 • 设计辅助: 用 AI 生成网站图标 (favicon) 和其他设计元素。 • 内容创作: 帮你起草产品文档和市场营销文案。 • 你的私人教师: 让 AI 逐行解释它生成的代码，帮助你学习和理解。 • 利用截图: 遇到界面 Bug 或想借鉴某个设计时，直接把截图发给 AI。 • 语音输入: 借助像 Aqua 这样的工具，你可以用每分钟 140 个单词的速度通过语音输入指令，比打字快得多。 持续改进 与 AI 的合作是一个不断磨合、共同进步的过程。 • 定期重构: 当你建立起完善的测试体系后，就可以大胆地、频繁地进行代码重构。 • 发现改进机会: 主动询问 AI，让它帮你找出代码中可以重构优化的部分。 • 紧跟潮流: 每个新模型发布后都去试试，了解最新的技术进展。 • 认识模型特长: 不同的模型有不同的“性格”和擅长的领域，学会在合适的任务中选择合适的模型。
AI编程工具激战：Claude Code、Gemini Cli崛起· 851 条信息
#AI 辅助编程 #Vibe Coding 指南 #版本控制 #测试框架 #持续改进
avatar
凡人小北
1个月前
去年我第一次用 Copilot，有点小震撼，自动补全几行代码、写个工具脚本爽得不行，心想：“以后大家差不多了，AI一上，谁还不是个工程师？” 现在回头看，这想法有点天真了。 真实情况是： AI 不但没抹平差距，反而把程序员之间的差距拉成了鸿沟。 以前顶尖程序员和普通程序员差 10 倍， 现在差的可能是 100 倍、1000 倍。 为啥？因为 AI 直把普通程序员的短板暴露出来了。 你以前靠写 for 循环、CRUD、接个接口混饭吃，AI 一上来，几秒写完。你价值直接被抹平。 但那些平时就擅长拆系统、搞架构的程序员，AI 简直是为他们量身打造的外挂。 特别是在 Cursor甚至 Claude Code加持下，给出更清晰意图，AI 秒写函数、重构模块，配合得像多年的搭子。关键是：你指令写得越准，反馈越强；你想不清楚，AI 也只能陪你绕圈。 过去写代码是“想 1 写 9”，现在变成“想 9 写 1”。 想不明白的，一样卡死；想得清楚的，效率爆炸。 而且这不是简单一句学不学 prompt 的问题， 是有没有那个“我知道这块应该用什么方法做”的系统建模能力。 到底是写代码的，还是在设计系统的，在 AI 面前会无限放大。 工具越来越聪明的时代，真正的差距只会转移到一个地方：一个人脑子里到底装了多少“不可替代的判断”。 AI 把“怎么做”给你代劳了，但“做什么 + 为什么这么做”那部分，只会更贵。
#AI 鸿沟 #程序员差距 #系统建模能力 #不可替代的判断 #AI 辅助编程
avatar
图拉鼎
2个月前
Claude Code，我也正式上车了：「AI 辅助编程」正式转向「全 AI 编程」…
AI编程工具激战：Claude Code、Gemini Cli崛起· 851 条信息
#Claude Code #AI 辅助编程 #全 AI 编程
avatar
宝玉
3个月前
我最初鼓吹 Claude Code 的时候，就特别说明了新手就不要去用了，因为你可能打开也不知道该干嘛！但是对于铁锤这样的老手来说，只是没切换思维模式，逼着自己用一段时间就会适应，并且习惯了就再也离不开了。 程序员熟手要用好 Claude Code，最大的转变来源于思维的转变和开发习惯的转变。 这个转变就是先设计再写提示词，然后用提示词生成代码。 “先设计再写代码”这话其实老生常谈，但是说和做是不一样的，虽然我们软件开发都号称是先设计再开发，那通常是针对整体的系统设计，但是到具体实现的时候，很少有人会这么做，因为编程的细节，它不是一下子就清晰的，就算你是个老手，在没实现过的模块，在没有写完的时候是没有完全想清楚的，只有去动手写，一边写一边想，写完一部分在调整甚至推翻重写，这样反反复复写完才算是把它搞明白了。 如果再让你把写过的模块重新实现一遍，那就简单直接多了，能很快写完，因为整个设计已经了然于胸，只剩下代码实现了。 写代码有些像写文章，你写作的速度是跟不上你脑子思考的速度的，所以你脑子构思好的东西，还要花很长时间的输出才能成文，类似的你思考好的架构要花时间才能写成代码并且编译运行。 但写代码又不完全像写文章，因为文字是有艺术性的，你的风格、用词、结构没有特定的套路，要反复斟酌，很费时间，AI 生成的文字很难满足这些方面的要求（有 AI 味），但代码无所谓，相对结构比较固定，而且能稳定运行的话，代码写的差一点也不是不可以接受。 所以写文章像我们这样天天写字的人，反而不太爱用 AI 写，因为它写出来的东西有一种奇怪的 AI 味，自己都不爱看更不要说你的读者了。 但是写代码不一样，你想清楚了设计，把设计写成提 Prompt，让 AI 去生成代码，以现在 Claude 4 的能力，并不会与你期望的有太大出入，如果有出入，要么就是小问题，再补加要求就能解决，甚至手动调整；如果有大的出入，那一定是你设计的问题，是你提示词没有写清楚，那么就回退一步，回滚代码，调整设计，重写提示词，那么就能重新生成正确。 这样设计到提示词，提示词再到代码的好处就是重构起来也特别容易，你不需要去大量手动修改代码，只要把重构的要求写成提示词，Claude Code 这样的 Agent 会很快帮你改好。 当然这样做的一个前提：就是每一次不要修改太多，不要生成太多代码，不然就可能会失控。 另一个改变就是：Review 代码和测试。 很多人没有 Review 代码的习惯，更没有测试自己代码的习惯，每次让 AI 生成代码，我都会仔细看一遍生成的结果，看代码和我期望的是不是一样的——如果我自己写，会怎么样写，它的方案是更好还是更早，更好我可以学习，也欣然接受，凑合那就这样了，不够好我就回滚调整提示词，或者追加一下要求。 测试也很重要，单元测试这种用例是要自己设计自己review的，手工测试也必不可少，尽可能让测试成本降低，比如通过命令行去测试、测试代码去测试，这样每次生成完都可以马上测试马上验证，有问题就回滚或者修复。 这样刚开始做是很不习惯的，但是当你适应后，你会喜欢这样的开发方式，结果也会更好。 顺便说一下，Swift 代码没问题的，我也用 Claude Code 写过的，质量很不错。
AI编程工具激战：Claude Code、Gemini Cli崛起· 851 条信息
#Claude Code #AI 辅助编程 #思维转变 #代码设计 #代码测试